JSConf.jp 雑まとめ
11/30
14:15 - 14:45
Room: C
14:45 - 15:15
Room: A
⭐ 15:30 - 16:00️
Room: A
⭐ 16:00 - 16:30
Room: B
17:15 - 17:45
Room: A
⭐ 18:15-18:45
Sponsor Talk
18:55 - 19:05
Room: A
19:25 - 19:35
Room: A
12/1
⭐ 11:00 - 11:30
Room: B
11:30 - 空き
⭐ 13:00 - 13:30
Room: A
⭐ 14:15 - 14:45
Room: B
15:30 - 16:00
Room: B
16:30 - 空き
⭐ 17:15 - 17:45
Room: A
17:45 - 空き
18:30 - 19:00
Room: A
Building and Deploying for the Modern Web with JAMstack - Guillermo Rauch | JSConf JP
rauchg
socket.io, Mongoose, Next.js, ZEIT CEO
Next.js 2017 年にリリース
multi page app
2018
static hosting
サーバレスFn
2019
Google Chrome collab
meta/hybrid framewok, StaticSIteGen
ソフトウェアエンジニアリングの世界は変わってきている
サーバフルからサーバレス
DataSourceからEdgeへ
テンプレートからコンポーネント
バックエンド -> フロントエンド
東京 Node 学園祭 -> JSConf.jp
abstraction からインタラクションへ
大きなバックエンドの関心事は堅牢な SaaS 環境
様々な SaaS とのインテグレーションな話（Auth, Datasourece, Payments, Search）
５年前
フルスタックなフレームワークが多かった（Rails, Django
JAMstack and サーバレスはフロントエンドにフォーカスした軽量のスタック
JS,API, Markup
後ろにあるのはサーバレスなど
Static の利点
cheap scaling
high availability
バックエンドのロードタイム reduce
O(1) TTFB -> 爆速
高いスループット
すばらしいセキュリティモデル
Static のデメリット
ビルドプロセスが長い
小さな変更でフルのリビルドが走る
SSR で解決できる
とはいえSSRは銀の弾丸ではない
ビジネスロジックの重複（サーバとクライアント）
保守運用が複雑、とってもコスト高
single region
安定性の問題とメモリリークの問題
高依存性、アドホックなキャッシュサービス（スケーリングする中で０
Node.js のセキュリティを狙った攻撃が増える
モニタリングが重複する、ｻﾊﾞｸﾗ
予測できない TTFB’（ブレが大きい）
500pages になると catastrophic
そこで JAMstack
Static の全ての利点を享受
様様なバックエンドを Plug できる
Markup はスタティック
Preloading & Pralleslism yeilds -> great performance
ZEIT で作った SWR の話かな？
No Data な場合？
Combine Static Site Generate
デモ
ヘッドレス CMS なフロントなやつ
CMSが更新されると同時に StiaticGenerate?（キック
JAMstack はすでにプロダクションで利用されている
LinkedIn, Twitter
App Shell を先に提供する
Next.js はどうなの？
Input: index.js -> Output: index.html… No getInitialProps
Divide ships per pages.
use fs, use dynamic, use lambda
Education
Design System
Deploy の変更
たくさんテストを書く総合的にやれ
デプロイがすべての中心になる
Test in Production
Blue Green deploy 的なテストをせよ
切り戻し容易にせよ
How to Boost Your Code with WebAssembly - FUJI Goro / @__gfx__
立ち見でメモなし
InversifyJSを用いたレイヤードアーキテクチャの構築 - 奥野 賢太郎
奥野さんがやってきたアプリケーションアーキテクチャ
DIP ってなんだっけ、密結合ってなんだっけ？な話
CFP の段階ではリリースしているはずだったがリリースしていない
テストバージョンの話
GCP メインで AWS は使ってない
Clound Run 出てるけど当時はなかったので App Engine
TS 3.6 で Express 4, client: Angular
密結合って？
コードを変更した際に変更が及ぶ範囲が想定しづらい
（予期しないところに影響が及ぶなど
ログイン、DB スキーマ、GUI いろいろが絡まり合う
例えば REST API
UI に必要なスキーマで JSON/DB もスキーマ
画面が変わってくると？
テーブルは古いデザインのまま
複雑で整合性が取れていない状態
画面だけリニューアルしてテーブルスキーマは古いママ
となると抽象的なインターフェイスが必要
= レイヤードする必要がある
これがレイヤードアーキテクチャ
ソロ開発
気がおもむくままに書くと無法地帯
スパゲッティが積み重なるか全てが絡んだスパゲッティになるか
例えば
ブラウザ UI と 永続化
クライアント領域 と バックエンド領域
もっとレイヤーを分ける
ブラウザ UI
ユースケース
抽象ストレージ
----- 境界 = HTTP -----
メディエイター
リポジトリ層
永続化
DDD の話
完璧に DDD をやっているという状態は難しい
ではやらないでいいかというとそういうわけではない
考えを借用する
MDD = モデル駆動開発
リポジトリ - データ永続の抽象化
リポジトリパターンとは
普通は DB というのは正規化というのが出てくる
複数のテーブルの読み書き
OCP 違反
違反を守れるのが リポジトリパターン
正規化されていないモデルの概念とDBのスキーマを分割
DB のコネクションをもつ必要がある
テスト可能にしておく
DIP
テストだけ、この環境だけこうするというのを可能にするのが DIP
SOLID の D
高レベルのモジュールが低レベルのモジュールに依存してはいけない
ピンとこない
https://gyazo.com/49761046c0e8b1b47bed96a002c7cedf
https://gyazo.com/54780875b0814735d07d20e55478721d
ファクトリー関数を呼んで UUID が変えるようになる
テストは Mock を呼ぶようにする
https://gyazo.com/51543338e4016908b619868f1da3f873
https://gyazo.com/577efcd1b8611343cb385be8ead7af4c
そこで DIP
コンストラクタインジェクション
それ以外もインジェクションの方法はある
そもそも Angular が持っているものと似ている
どう使うか
Express HTTP handler
router から mediator に飛ぶ（UserMethodMediator, e.g. UserGetMediator）
mediator
読み書きをここで行う
repository
ここで永続化をするわけではない
reader, witer
UserReader, UserWriter みたいなものがいる
リレーションごとに存在
database provider
コネクションをもつだけ、トランザクションを管理するだけのレイヤー
GCP Cloud SQL
まずはインスタンスの寿命をきにする、短くする
https://gyazo.com/0c9b13fd021a53564c353369028986a8
https://gyazo.com/4191c38482beb4ad8c98200c13a9a9ad
DDD の中では VO バリューオブジェクト
例えば、UserId 型、UserName 型、Email 型など
関数化してもあちこちに存在することになる
コンストラクタで書いて弾いてしまう（if 文で弾く
= インスタンスの寿命を短くする
コンパイルセーフな状態
NestJS 使わなかったんですか？
express 拡張
Angular によく似てデコレータ使いまくってる
サーバで Angular でやりたいわけじゃなかった
DI コンテナを学んで保守しやすいアプリケーションを
Web の自重 - Jxck
Chrome 一強の状況って本当に健全なのかっていう問題提起しろ by 会長
テーマがおもすぎる（30分では）
結構圧縮
じじゅう（じちょうじゃない）self gravity
Web とは？
これまでの HTTP のコンテキストでは語ることができないのではないか
Web 自体の仕様はない
Tim 御大の全てではない
Web は何をするものなのか、という定義・制限はない
今の Web は Web じゃないみたいな話をしてもしょうがない
仕様策定のうえで Web に必要なの？ みたいな議論が必ず発生する
Web はこういうものをするものだという議論は成り立たない（それぞれのコンテキストで変わる
新しい仕様のケース
Web に必要かどうかの議論ではない
それが今の Web のモデル上で設計できるかどうかを議論する
まずは互換性を壊さずに成立するのか、既存のもので成立するのか
重要なのはセキュリティの考慮
Same-Origin 系の話、ユーザのプライバシーを守れるのか Moziila Specification Position
仕様にい対するポジションが展開されている
Harmful なものが2つ上がっている
SxP が harmful -> 今のままではユーザに危険性がある
ユースケースベースでは否定されるわけではない
では、技術や仕様よりも Usecase 自体を我々は Web と呼んでいるのではないか？
Webとはユースケース
ユースケースベースで出来上がっている仕様
ユースケースが増えれば増えるだけ仕様が増えていくというのが大きな流れ
Web を支える仕様が様々ある
MDN の話
Web の仕様を一元管理しようねという話が上がってる（MS と Google でやろうねって話なってたよね
RFC は8000番台を超える
実装しないとユースケースが実現できないのでモダンブラウザへの要求が肥大化（後方互換性）
人類はブラウザをまたゼロから作ることができるのだろうか
いまあるメジャーブラウザが生き残れるのか
当時 Google やめたばかりの及川さん、ゼロから作るというより途中から作るということになりそう
Edge -> Chromium
ゼロから作るとは Chromium から作るということになるのでは？
ブラウザの多様性ではなかった、Chromium を使って如何に自分らしく（ブラウザが）あるか
ユーザにとってのより良い GUI とは、みたいな
本質、多様性が減ることより増やすことが出来ない
Web は自重で潰れてしまうのではないか（漠然とした不安はこっちだった）
どうやればユースケースをへらすことができるか？ => できない
仕様はレイヤーを下げることができる
border style -> 仕様を追加するのではない -> Houdini Paint API
border の仕様策定は止めて低レイヤーから策定する
レイヤーを下げることで責務をブラウザからアプリケーションに移譲する
ドキュメントよりも UI Tookit
portal がほしいとかさ
カスタマイズされるスタック
今あるスタックは Work しているが Fit していない（HTTPは GraphQLへ、DOM は VDOM へ）
実はゲームは API が足りない
実はデバイスアクセスも API が足りない
任意のバイナリを任意の場所へトランスポートできればいいんじゃないか
デバイスアクセスの API 多い
パーミッション、CFP、WebUSB、NFC
Game が外レイヤー、App レイヤー、その中に HyperMedia（HTML...）、の下に OS
GUI は HTML である必要はない、Canvas で独自に描くこともできる
ユースケースは OS レイヤーから
ekioh ?
Flow というブラウザの話
GPU multicore を使い切るためのブラウザ
ゲームの知見ベースで作られている（Gmail が表示できるようになった
まとめ
多様性、本質は Web の肥大化
ユースケースを仕様でカバーすると肥大が続く
レイヤーを OS レイヤーにしてアプリに移譲
ユースケースは低レベルを求めている
おまけ
Flutter って実は Unity みたいなことをしようとしている
Web の再構築を考えて作らたのが Flutter ?
OS レイヤーの API を利用した SDK を作ればアプリケーション作れそう
OS レイヤーの API がありさえすればいいんじゃなかろうか
ブラウザって C とかで書かれてるんでしょ？
バイナリ落としてきてブラウザが動くんじゃないの？
WASM で動かせれば未来があるんじゃないの？
なるほどｗ
GraphQLを用いたECサイトにおけるパフォーマンス改善 - 澤井宣彦
FiNC の方
FiNC -> ヘルスケア特化のプラットフォーム
メディア、インタラクティブ、いろいろはいってるのかな
EC サイトもある（Web）
EC サイトは歴史の長いサービス
2015〜 Rails erb で HTML
リニューアルプロジェクト
社内のリブランディング目的
ページ遷移が重かったので SPA、GraphQLなどを採用
リリースタイミングはシビア
運用ももちろんある
外部ベンダーを使って画面のスタイルなど
スコアが 8 点
-> パフォーマンス改善して 48 に
この過程がメインの話
（フロントのチューニング）GraphQL のチューニングがメインだった
クライアントに自由度がある
Over-Fetching
Gragment
Persisted Query
技術構成
Rails -> React + TypeScript
バックエンドは既存の Rails API を利用
トップページをリッチにする施策
レンダリングサーバは Node.js
SSR のときは Node.js サーバに飛んでまたいで Rails にリクエスト飛ばしてHTML構築
パフォーマンス計測について
実機でテスト
合成環境でテスト（sythetic test）
PageSpeedInsight
Audits（Chrome）
改善戦略
クライアントサイドはバンドルサイズ
GraphQL の改善はクライアント・サーバ両方からアプローチする必要がある
フロントの改善
Audits でレンダリングを妨げるサブリソースの話
問題はコンポーネントと紐付かない CSS がページに読み込まれていた
クリティカルレンダリングパスな CSS 読込
ここはさらっと
gzip 圧縮が効いてなかった
Nginx で Content-Type が指定されてなかった このへんで Audits 25 点
バックエンドの改善
Datadog APM を活用（すでに導入済みだった）
レスポンスタイムが 1.5 s !
何故遅かったのか？
クエリを束ねて投げていた
各コンポーネントに必要なクエリをまとめてリクエスト
APM から
クライアントから送られてくるクエリを確認
parse, validation が先に走ってから処理
GraphQL trace の読み解き方
N+1問題
batch-loader のようなものが Ruby にはある、盛り込み済
（trace の読み方勉強したいなあ）
なんや、フロントの問題かいな
over-fetching している
クエリと Schema の改善
2つの問題
ページングがないリクエストをしている
まったく使用していないものをリクエストしている
ページング
開発環境だとデータが少ないので忘れがち
配列を返すクエリがページングを持たないほうが問題
スキーマをリントするのがある
使ってないクエリ
消せば良いが再発防止は？
画面で使ってないかどうかを知る手立てを見つける必要がある
https://gyazo.com/1074b2ad8595833e1556e4dc56fb8d80
こいつが Over-Fetching
クエリとコンポーネントのひも付き
Fragment, Collocation
Fragment はクエリの部分定義
再取得ではなく
App Component
上流で全てクエリを束ねていた
コンポーネントの階層とクエリの階層をマッチさせる
クエリの最適化をしたことで前述の 48 点になった
今後
キャッシュをうまく使えないか
リアルタイム性が高いものだけではない
未ログインは CDN でキャッシュを返すなどできるはず
GraphQL はキャッシュできないという誤解
GraphQL は別に POST で送る必要がない、GET でも良い
これちゃんと覚えておこう
Your benchmark may not guide a real application performance - Tetsuharu OHZEKI
OHZEKI さん「いま無職」で草
テンション高いｗ
早いソフトウェアは好きですよね？
遅いソフトウェアはみんな嫌いである
エンジニアリングの満足ではない
UX 良くなる
マーケティング上の価値がある
ソフトウェアを早くするにはどうするか？
むやみに最適化してもしょうがない
推測するな、計測せよが鉄則
ソフトウェアのパフォーマンスを如何に計測するか
定量的な計測をしっかりとっていく
早くなっているか遅くなっているかをきちんと確認
定常的にとってないのと早くなってもそのうち遅くなる
ベンチが何をはかってるのか？
きちんとしたベンチマークをとれていますか？
アプリケーションが求めるベンチマークをとれていますか？
ゴール
リアルなシナリオがもっとも重要
このセッションでパフォーマンスチューニングの際の知見になれれば
動画ストリーミングサービスの例えば
コアバリューは何なのか？ -> ユーザが動画を見てくれること
ユーザがページを開いて動画を見る上で重要なメトリクスは？
FCP? TTI？ いったいなんだろう？
これらの指標がいいのに動画が再生されるのに 30 秒だとしたら？ 価値ではないよね
一般的に言われるメトリクスが本当にプロダクトに必要な指標なのか？を知るべき
アプリケーションの起動速度では十分に計測できない
ユーザの体験の向上はメトリクスを上げることだけが重要ではない
自分たち固有の指標をもとにする必要がある
自分たちで決めるのが重要
とりあえず Lighthouse ではかりましょう、は不十分
アプリケーションがどのように動作するのかシナリオに沿って指標を取るべき
3G、4G といった帯域などは個体差が多くて再現しづらい
シナリオ ＝ ユースケース
JS のコスト換算は難しい
Profile 上では 1ms 関数を数実行したらそれでいいんだっけ？
JSVMは早いとよく言われる
何が早いのか？ 実行時に動的に最適化される、TurboFan の話かな
JS Engine には JIT には 4 段階の戦略がる（まあ似たような構成をもっているものも多い）
あまり実行されないコードは最適化されない
マイクロベンチのとり方での間違い、少なく実行されるコードのマイクロベンチって意味あるの？
本当にはやしたい関数を本当にユースケースレベルにあっているのか
グラフ
数回目以降は最適化の傾向がある
途中のスパイクは他要因
Jetstream2（prepack, air ちょっと話ついていけてない）
JSVM のベンチを取りたいわけではなくアプリケーションのユースケースレベルで取りたいはず
判断材料としてあっているのか
実際のワークロードはユースケースにあったメトリクス
破綻したベンチで直し続けるとコードが壊れていく
間違った最適化
クリティカルパスな話
ページロード時、パーサブロッキングがあった、defer 直した、サブリソースの読込は解決
肝心なアプリケーションは FMP が上がらなかった
なぜ？
実際のクリティカルパスではなくスクリプトが読み込んだもの自体にボトルネックがあった
ボトルネック -> boostrap コード
実はちょっとだけしか処理されずプロファイルには現れなかった
プロファイルはごく稀に誤ったものを示す場合がある？
ボトルネックを探すのは難しい
トラフィックをはかるためのベンチマークサイトがある
実は全く関係ないもので表示されている（あとでスライド見よ）
全体のうち 59% はレンダリングエンジンのペイント処理でネットワークが遅いみたいに見えてたｗ
学び
クリティカルパスとは…HyperVisor なりもっと低レイヤーから深い洞察が求められる
それらをもとに様々なツールを使って総合的な観点で見ていかないと問題をあぶり出せない
誤ったベンチからどう改善してパフォーマンスを上げてくか？
「プログラムを早くするには遅くなることをしないこと」ある Webkit のページ
もとより遅くなってる！を避ける
CI で回して計測し続ける
コミットごとにはばらつきがある
もちろん別で利用しているインスタンスの影響
OS の中で別のプロセス、サービスが動いている影響
長期的なトレンドに着目すること（一つひとつのコミットに着目しない？
サクッと再現可能に立ち上がり容易に再現できるのが大事
早くなるコミットの中に遅くなるコミットがあってもトータルで早くなる
まとめ
パフォーマンスを改善するにはリアルな指標が重要
リアルな指標に基づいた改善が必須
ボトルネックを洗い出すにはプロダクトのドメイン理解が重要
アプリケーションが何をしているか理解することも
ブラウザベンダを例にしてきたがなるべく小さな粒度で長期的に計測
何をすれば早くなり遅くなるかが徐々に理解できるようになる
ソフトウェアを早くしたいならば
-> 自分たちのストーリーを作り計測するところからはじめよう
Pika: レジストリの再創造 - Fred K. Schott
CRA の依存の数の話
ビジュアライザー（バンドルアナライザ
どちゃくそ依存多い
AddyOsmani
実際のサイトでバンドルの中に重複した react-dom があった
自己紹介の画像が小さい頃の画像でかわいい
Pika
未来の開発での大きな賭けとなるプロジェクト
未来の開発って？
80% 必要なツーリングを減らす
開発速度を 10x にする
ウェブサイトは 10x 速くする
2009年の話
script 行の数よwww
AMDっていうのが発明された
define 懐かしい
次に登場するのが CommonJS
CJS = Browserfy はバンドルするというステップが開発に出てくる
で、ESM
Browser は CJS を理解できない
88%のブラウザでは ESM が使用可能（caniuse）
手始めに解決できたのか
賭け1 必要なツーリングを80% less
npm package download をブラウザで実行
Pika/web は Snowpack という名前に？
package.json
prepare に snowpack を指定
snowpack --optimize（オプションが見えなかった
CRA 205MB, snopack 25.2MB
snowpackコマンドを走らせることで、dependnciesをブラウザでもうごく形でweb_modulesフォルダに保存する
賭け 2 開発速度を 10x に
バンドルするたびにビルドスピードが早くなる
snowpack はビルドレスで開発が可能になる
アンバンドル開発
without bundler
watch スクリプト
web_bundle(??)/みたいなディレクトリにモジュール持ってくるのかしら？
仕組みがまだ理解できていない
Buildless
開発においてまず先にバンドラをどれにするか選ぶと思う
賭け 3 10x ウェブサイトを速くする
モダンなサイトの 97% のコードは npm からやってくる
つまりサードパーティ
Download React を何度も何度もやることになるよね（同じリソースなのにウェブサイトを回るたびにダウンロード
import "https;/cdn.pika.dev/react/v16"
これって堅牢な CDN でないと結構きつそう？
配信元は可用
例えば全てをバンドルしないとしてそれってパフォーマンス的な問題ってどうなるんだろう
名前空間や JSX to factory fn への変換とか気になる
ESM はめっちゃクール
ESM は3つの課題がクリア出来そう